OpenCPN 3.1.x is downward compatible with all previously built and/or distributed Plugins:
So, as a Plugin Developer, the model to follow is:
Plugin API Designation found in the github/[plugin}_pi/src/[pluginname].h file: #define MY_API_VERSION_MAJOR 1 #define MY_API_VERSION_MINOR 13
lib_ [PluginName]_ [OSdesignation]_pi [Plugin-API]_v [VersionNumber]_pi.dll
eg: lib_aisradar_win32_pi18_v32_pi.dll
eg: lib_aisradar_win32_pi.dll (Simpler version)
eg: lib_aisradar_win32_pi18_v32_pi.exe (as an executable)
In plugin filenames there generally be will be a designation as above (it is part of the plugin filename format).
It tells which API version is needed and, if it was built against the right codebase, with which version it should run - Startup of Opencpn leaves messages in the opencpn.log regarding the status of each plugin. If the plugin is not installed because the current Opencpn version does not support it, the piXXX designation will help you decipher what the problem is and what can be done.
pi18 (1.8) = OpenCPN 3.0 [Use oldest supported Opencpn 3.2.2]
pi19 (1.9) = OpenCPN 3.2 [Use oldest supported Opencpn 3.2.2]
pi19 (1.9) = OpenCPN 3.2.2 [Oldest supported version]
pi110 (1.10) = OpenCPN 3.3.x
pi110 (1.10) = OpenCPN 3.4 <—wxWidgets 2.8.1 used
pi111 (1.11) = OpenCPN 3.4 <—wxWidgets 2.8.1 used
pi112 (1.12) = OpenCPN 3.4 <—wxWidgets 2.8.1 used
pi112 (1.12) = OpenCPN 4.0 <—wxWidgets 2.8.1 used
pi113 (1.13) = OpenCPN 4.1 <—wxWidgets 3.0.2 first used
pi113 (1.13) = OpenCPN 4.2 ←SVG Icons added (gtk,expat,vc,etc)
pi114 (1.14) = OpenCPN 4.5.307 ←Externalize AIS drwg #795 -Rel.Candidate
pi114 (1.14) = OpenCPN 4.8.0 See Note just below, when API 1.14 was fixed
pi114 (1.14) = OpenCPN 4.8.0 Changed API 1.14 to work in MS Windows for BR24beta
pi115 (1.15) = OpenCPN 4.8.2
pi116 (1.16) = OpenCPN 4.99 (5.00 or ov50) <—wxWidgets 3.1.2 first used
pi117 (1.17) = OpenCPN 5.x with wxWidgets 3.1.2, new Plugin Manager,
Sourceforge files are not as complete.
The Main program API number is distinct and independent from the OpenCPN Version number. Each released version of OCPN will support a certain PlugIn API. As we progress, we expect the API eventually to stabilize, or at least to evolve more slowly than the main program. This will happen naturally as we fill out the API to include the commonly required Plugin functions.
I think it would be a great idea to bring some order to the Plugin constellation. There may be some renaming of existing Plugins required, but that's OK at this point. We definitely ask all Plugin developers to try to follow the naming convention during their development, and especially after their release. One can see at a glance what the requirements of a particular Plugin will be.